Magnum One/Magnum One (Mid-American Digital) (Disc Manufacturing).iso/d20/mamm_102.arc/MT_102.TXT

Text File | 1991-09-28 | 35KB | 1,131 lines

Preamble

Copyright 1991 Greylock Software, Inc.

   Greylock Software, Inc.
   POBox 730
   Gt Barrington MA 01230
   Data: 413-243-0034
   EMail: 1:321/202@fidonet


Intended Audience


Synopsis

   This is a brief description of MilqueToast, with both its
   similarities and differences from BinkleyTerm.

   This document is for the 0.86 version of MT.


Contents

Milque.Res


Milque.Lng

   Eventually, the language file will be totally eliminated from
   MilqueToast, in favor of resource file based solutions.  However,
   we wanted to extend some of the language file functionality for
   Bink proper, so the conversion would be consistent between the
   two versions.


MT.Exe


MT_086.Txt

   Yes, the last beta was 0.97.  What's it to you?


1  Features

1.1  BinkleyTerm With A Windows-Like Interface

1.1.1  Mouse Support


1.1.2  Where Simple, Extensions


1.2  Code More Or Less Concurrent With Bink 2.50

   At the present time, the code for Milque is virtually identical
   to the 2.50 BinkleyTerm code.


2  Differences From "Standard" Bink

2.1   ComboBox In Kill Traffic

   Yoy may note a combo in the Kill Traffic dialog.  Eventually,
   there will be combo boxes in all the dialog boxes, derived from
   FidoUser.Lst or the nodelist itself.


2.2   Environmental, Config Files Called Milque

   The environmental used to determine the config file path is
   MILQUE.

   The Config file is Milque.Cfg.  The event file is Milque.Evt.

   The language file is now called Milque.Lng, rather than
   MilqueL.Lng.  (Early development of Milque was medium model.  Now
   that Bink is large model, this is no longer necessary.)

   The semaphore and related files are prefixed Milq.


2.3   Gateway Mode Triggered By Alt-Minus, Not Alt-Equal

   This will be rectified when after I've talked to Magma about the
   problem.


2.4   Keyboard Remapping Does Not Function In Milque

   The keyboard remapping facility in the Bink language file is NOT
   USED by Milq.  The irony of this is we put that facility INTO
   Bink in the first place!  Filling out this table in the language
   file will merely consume memory needlessly.

   The reason for this is the way MEWEL/Windows processes events,
   menus, and accelerators.  In a MEWEL/Windows application, if you
   have an active menu and you press Alt and the first letter of one
   of those menu items, that menu will be pulled down.

   The "legal" way to subvert this is by the use of accelerators.
   Accelerators are generally stored in the resource file (which we
   are doing.)  Unfortunately, we have yet to resolve the legal
   issues involved in distributing the MEWEL side resource compiler,
   and know little or nothing about the legal status of Windows
   resource compilers.  (The MEWEL resource language format is close
   to identical to the Windows format.)

   We are considering making use of the keyboard remapping in the
   language file as an "on the fly" accelerator table.  Even in this
   case, it should be noted that MEWEL/Windows keystroke values are
   different than DOS keystroke values.


2.5   Overlaid With VROOMM

   Found the major oops that was causing us problems with the
   overlaid version.

   The current version is overlaid using BorlandC VROOMM.  This
   means if you are running the beast on a file server, you should
   be careful not to run it more than once from the same image at
   the same time.


2.6   Product Code Table Derived From Resource File, Not Language


2.7   Screen "Blanking" Quite A Bit Different

   Screen blanking involves "iconizing" the main window, and moving
   it around the screen at randomly.

   In addition, we have divorced the screen blank time from the
   modem init time in Milque.

   Finally, a new config verb, BlankWait [Seconds] has been added to
   the config file.  If it is not specified, 60 is used.


2.8   Terminal Mode Is Marginally Operational

   Terminal Mode is marginally (barely) operational.

   ANSI is internal to Milque.  The implementation is not complete.
   However, it has been generalized to the point that eventually, it
   can be used relatively easily in Bink proper.

   However, few of the function keys have been implemented, none
   fully.  Alt-D, Alt-M and Alt-Y should work.


2.9   Version 7 NodeList Is The Default!


2.10  Windows Are Sizeable, Moveable, And Storable

   Windows are sizeable and moveable, and should still work as you
   would expect.  If you resize the recent activity window by
   shrinking the number of columns, and increase the number of lines
   in the Pending window, all the lines in the pending window should
   be used (if needed.)

   The "focus" of Mailer mode can be changed by clicking on the
   window you wish to have focus, or by tabbing from Window to
   Window.  You can change the position by grabbing the caption bar,
   or from the move option of the system menu for that window.  The
   system menu is accessed by clicking on the system menu box for
   that window, or by pressing alt-space.  The size of the window
   can be changed by grabbing the lower right hand corner of the
   window, or via the size option of the system menu.

   The state of the windows is stored in a file called Milque.Scr.
   This is written to by the Save Layout command in the File menu.
   The original layout can be loaded from the Original Layout
   command from the file menu.


3  Current Status

3.1  Operating Full Time On JonesNose For 50+ Days

   We've been running MilqueToast for approximately 10 days on
   JonesNose, full time.


3.2  Release Features

3.2.1  1.10

3.2.1.1  1.02 (910928)

3.2.1.1.1  By Node Misc Information

3.2.1.1.1.1  General Discussion

   There's some seriously experimental code in this version which
   takes advantage of a "feature" of Version 7 nodelists to have
   variable length records.

   With the help of Scott Samet, and a special version of Xlaxnode,
   we have the ability to append application specific information to
   nodelist records (in V7 mode.)  Initially, we are using this
   feature to enable or disable certain enhancements on a node by
   node basis.

   For instance, suppose, in general, you do not support paths in
   general, using any of the "class" brushes, but you do wish to
   support it for an individual node (say, perhaps, mine.)  You have
   not SendPath or PathMap flavored statements in your Milque.Cfg.

   In your Xlaxnode.Ctl file, you add the following line:

     MISCDATA SendPaths=1,PathMap=Full.Map,Inbound=E:\Special

   The following tokens are supported:

     Token          Argument
     ============== =========================
     Inbound        Path
     MaxBytes       Byte Count (Long)
     MaxTime        Minutes (Integer)
     OKFile         File Name
     PathMap        File Name
     ReqLim         File Count (Integer)
     SendPaths      Boolean (Integer)

   Note we have chosen to implement this only in V7 nodelists.  It
   is possible to add this to V6 nodelists, with a good sized BUT:
   EACH RECORD MUST HAVE THE SAME AMOUNT OF MISC SPACE.  For those
   already complaining about nodelist size, this is prohibitive.
   Rather than even try to fight that battle, and since we plan to
   ELIMINATE V6 support from Milq in the near future, we are
   expending no effort to extending this solution beyond V7
   nodelists.


3.2.1.1.1.2  Other Approaches

   We are looking at some other approaches to this general set of
   problems.  These may be taken in combination with or in
   replacement of some of the existing solutions.

   One of the approaches we are considering is the use of one of the
   flag bits, to indicate a "special friend".  This would be a
   fourth level of security, above protected, and would mean that
   all those sets of three verbs would become sets of four, not an
   entirely attractive side effect.

   We also need to consider session by session access to some of
   these facilities.


3.2.1.1.1.3  Caveats

   First and foremost, this is EXPERIMENTAL.  While we are committed
   to the concept of "node specific" overrides, we are not locked
   into this particular implementation.  Even if we stay with this
   general implementation, there will probably be some fine tuning
   that may cause problems between versions.

   This information can only be embedded by Xlaxnode.  It cannot be
   EXPANDED on the fly (although it can be contracted or altered,
   with care.)

   You must use the =1 form of the token rather than just the
   presence of the token for this pass.  (This restriction will be
   removed.)  You must use the "lowest common denominator" config
   file tokens.  For example, regardless of whether you are unknown,
   known, or protected, if you want to override the inbound, you use
   the token "Inbound=[Path]".

   The list of tokens is neither complete nor guaranteed.  Items
   that aren't on it may be added.  Items that are on it may be
   dropped.


3.2.1.1.1.4  Scott Samet's Tech Notes

   Harry Lee and I have formulated what is hopefully an open-ended
   extension to the V7 nodelist. Additional, variable length,
   optional data is appended to the end of the V7 record.

   The size of this data is added to the "packed_len" byte, so that
   the record length is still the sum of the fixed part plus the
   phone, password and packed_len values.

   It was done this way to minimize the impact on existing
   programs.  I have not done extensive testing, but NFind, as well
   as all my own utilties seem to ignore the new data.

   The existing BName_len, CName_len, and SName_len fields are
   unchanged, and the actual length of the packed data is also
   unchanged.  It can be computed as:

     PLen = Truncate ((BName_Len + CName_Len + SName_Len + 2) div 3
   * 2)

   (Packed_len - PLen) is the number of bytes of extended data
   present.  If zero, there is none.  This data consists of one or
   more elements of the following format:

       An id-type byte:
          00-3F = one byte data element follows
          40-7F = two bytes data element follow
          80-BF = four bytes data element follows
          C0-FF = variable length data, consisting of a length byte
                  followed by the actual data.

   At the present time, C0 is the only id-byte used, and that's for
   data used by Milquetoast.  I'll let Harry document the exact
   purpose.

   To prevent duplication and confusion, I suggest that a single
   person act as the registrar and assign id-byte values as
   required.  I'll be happy to do this, but it might be better if it
   was someone closer to the development cycle.


3.2.1.1.2  CGA Fix

   We have integrated new code from Magma Systems to resolve the CGA
   problem.

   This current code forces the use of the BIOS.  New code which
   writes directly and optionally checks the retrace bit is on the
   way.


3.2.1.1.3  Path Support Improvements

3.2.1.1.3.1  @Include.Ext - Nested Include


3.2.1.1.4  Windows

   Most of the work in this version is behind the scenes, to
   accomodate the concurrent WinApp development.

   "This is worse than diverticulitus" he whined.

   Essentially, we are trying to cope with this problem through the
   magic of macros on the first cut.  Once we have learned all the
   points of conflict, we will make a second cut, orienting the
   PRIMARY code to be Windows, and the secondary code to be MEWEL.
   Primary DEVELOPMENT will probably continue in MEWEL.

   Unfortunately, what this generally means is the following cycle:

     Compile until you hit some errors

     Make macros (in Milq.H) to correct for them

     Recompile Simple MT

     Recompile Simple BT

     Go To Top

   It's about a twenty-five minute cycle.  Even when you skip the
   rebuilds (which I sometimes do), it is painful.


3.2.1.2  1.01 (910922)

3.2.1.2.1  Bell Support Added To ANSI Module


3.2.1.2.2  Path Transmission/Reception

   Milq will send, receive, and use path information in ZedZap and
   Janus sessions.

   This feature is a powerful one, with great potential for system
   abuse.  We do not recommend you enable it until you think you
   thoroughly understand it.

   I program for myself, figuring what I find useful, someone else
   might as well.  We do all our backups using FidoNet technology.
   We LHA our work into a set of archives every day, and exchange
   them between a few systems.  At 9600, this can take an hour, but
   who cares?  It's a local call, and this way the backups are done,
   period.

   Way back when, we used EMCL (TICK) technology to handle this, but
   we ran into problems doing this.  We needed finer control of
   where the mail agent put the files.  We needed access to ZSkip.

   Initially, we put some code in Bink that allowed for node
   specific individual inbound directories, if they existed.  Still,
   even this caused problems.  While it isolated my files from the
   "general inbound", it made difficult the task of discriminating
   between files sent for backup, and files sent for other reasons.
   We have abandoned these changes, although I believe there's still
   something to be said for them, they may be restored in
   conditionally compiled code.  We needed still finer control of
   where the mail agent put the files.  We need to be able to
   transfer and map path information, in effect, providing full
   access to any path on the system.

   Three config file verbs are added: PathMap, KnownPathMap, and
   ProtPathMap.  These each take a filename as an argument, pointing
   to a file of lines of the following format:

     \SrcPath D:\DstPath

   Slashes are not "directional sensitive"!

   We plan on allowing the nesting of these files, using
   @filename.ext.  We also plan to allow prefix only substitution
   (for now, an exact match is required.)  And we plan to allow (in
   a controlled manner) for some systems to be able to create paths
   that do not exist in the substitution table.

   Currently, this only is used on the receive side.  We will
   probably implement it on the send side as well, which would allow
   you to "hide" your directory structure while still taking
   advantage of the feature.

   Three other verbs control the SENDING of paths (SendPaths,
   KnownSendPaths, and ProtSendPaths).

   There are restrictions on this feature.  It will only work when
   you are communicating with a Bink, Igor, or Milque which also
   supports this feature, something determined by examining the
   product code information transmitted in the YooHoo handshake.
   Currently, only beta level software supports this.  (Milq 1.01+
   and Bink 2.51/GS handle it.)

   Why these restrictions?  Well, first the easy one.  So far as we
   can tell, only ZModem based protocols have provisions to transfer
   path information.  This doesn't completely explain the product
   restrictions, since many products support the appropriate
   protocols.  When we first enabled this feature, we discovered
   that at least one mailer does not properly implement ZModem, and
   is quite unhappy if you send it a path.  Rather than code in the
   "bad" mailers, we coded in the "good" ones.  In addition, even
   the Janus code within earlier versions of Bink (Igor and Milq)
   exhibits this weakness.

   WARNING!  As of this writing, ONLY the 2.51-YYMMDDHHMM version of
   Bink (the one we produce) will properly handle this, and there
   could be problems with Janus sessions if Bink proper does not
   nuke paths on the receive side with betas at or above 2.51!

   At the current time, these restrictions are contained in a hard
   coded table.  We will probably move this table to either the
   resource or language file, to allow the enabling of this feature
   with other products as possible without recompiling.

   In addition, we are still considering mechanisms to regulate this
   feature on a node by node basis, in addition to the "node class"
   basis initially implemented.  We are trying to accomplish this
   with a minimum of node specific files.

   Let's briefly outline some of the inherent "gotcha's" in this
   little ditty.  If you allow someone mapped access to your the
   directory the running MT.Exe is in, very odd things could happen
   if someone uploaded a new MT.Exe.  I don't even want to think
   about this one.

   If you happen to map his "outbound" information to somewhere
   other than your inbound, mail might not get unpacked properly.

   If you allow mapped access to configuration directories, backup
   directories, or program directories, obvious security breaches
   are possible.


3.2.1.2.3  Resource File Cleanup


3.2.1.2.4  XMRcv Status Display Cleanup

   XModem (FTS, etc.) type sessions were not being properly
   displayed.  Hopefully fixed.


3.2.1.2.5  Yet Again Fixing The Damned Nodelist

   Someone merging the code decided they didn't like the way we had
   done nodelist code, so they got clever.

   Not clever enough.

   Once again, we have put the code back to the way it was.

   Version6 now works again.

   I've set up my development machine with a V6 nodelist only.  Such
   errors will be detected in the future.


3.2.1.2.6  YooHoo State Table Code Integrated


3.2.2  1.00

3.2.2.1  Vrsn 0.99 (910914)

3.2.2.1.1  Scheduler Improvements

   The Schedule list has been enhanced both with regard to the
   amount of schedule information displayed, along with allowing you
   to actually manipulate the information.

   The Write button takes the changes you have made and commits them
   to memory, and, when you leave Milq, saving them in the .Scd
   file.  It does NOT affect the .Evt (text format) file.  This is
   accomplished by using the Export function.  In other words, the
   changes you make will "stick" when you use the write button until
   you update the .Evt file or erase the .Scd file.

   Currently, the Export button generates a file called Event.New.
   This is basically done out of cowardice on my part.  It appears
   to be a functioning event file, but since I don't have a very
   complex event file, I'm not sure this is true.


3.2.2.1.2  Graphics Support

   Graphics Mode has been enabled, although all the ramifications
   have yet to be ironed out.

   To enable graphics mode at program start, in Milque.Ini, set
   GraphicsMode=16 (or whatever mode is best for your system.)  It
   is recommended you NOT use EGA=1 in this case.

   All this stuff will be cleaned up in the 1.10 release.


3.2.2.2  Vrsn 0.71

3.2.2.2.1  Merge To 2.49n Level Source


3.2.2.2.2  Terminal Side Resource File Fixes


3.2.2.3  Vrsn 0.86 (910901)

3.2.2.3.1  Code Merge

   Milque code is now virtually identical to Bink code, at least in
   those modules that are common between the two.

   This was the result of a lot of effort on Vince's part.  Thanks,
   Vince!


3.2.2.3.2  Nav Keys Hosed

   The Pending Window Navigation Keys are somewhat problematic.

   In order to provide access to their functionality while we work
   these kinks out, we set up the following accelerators (case
   independent):

     D - Down a Line
     E - End
     H - Home
     N - Next Screenful
     P - Previous Screenful
     U - Up a Line


3.2.2.4  Vrsn 0.85 (910831)

3.2.2.4.1  Attempted Cleanup of "modal" modeless window problems

   A number of bugs were found in the code that sets the "mode" of
   the Status and Pending windows.  These have been eliminated, we
   hope.


3.2.2.4.2  Event List Dialog Box Added

   An Event List dialog has been added.  It's a hint of things to
   come more than anything at the current time.


3.2.2.4.3  Merging To k Level Source (2.49-7+)/Code Cleanup

   This was not fun.

   No, that's being nice.

   This was downright painful.  It was also profound in the number
   of areas it touched.  Please test EVERYTHING.

   Much of the Windows specific code has been removed from Bink
   proper, in favor of macro changes, explained in detail in the
   0.84 notes.


3.2.2.4.4  NewNodeList BugFix

   NewNodeList was broken in 0.84.  It's fixed now.

   The default remains Version 7, but specifying NewNodeList will
   work now.


3.2.2.4.5  Path Send Problems

   Milque is experimenting with handling paths during WaZOO based
   sessions.  Essentially, we plan on a mechanism that will allow
   systems to transfer files between ACTUAL PATHS, bypassing the
   inbound directories, under controlled conditions.

   As a precursor to this, we set Milq to ALWAYS send the full
   path.  This has caused problems at least with dBridge systems.
   The problem is one of compliance with the ZModem spec, which
   specifies that paths are allowed.

   The short term solution to this will be to send path names ONLY
   to other Milqs (and Binks).  This is not a great solution (one we
   will NOT extend on a case by case basis).  However, we cannot see
   the point in adding a bit to the WaZOO handshake for a capability
   we should already be able to legally support with the information
   already being transferred.  Nor will we make Milq aware on a
   mailer by mailer basis who is and is not capable of handing
   this.  Both these solutions are "proving the negative".

   Milq will ONLY send paths if SendPaths=1 exists in Milque.Ini.
   This verb may be moved to Milque.Cfg before the formal release.

   The real solution, in short, is compliance.


3.2.2.4.6  Pending Window Keys Different From Binkley

   Due to the limitations of accelerator keys (described elsewhere),
   we have been forced to change the keys used to manipulate the
   pending outbound window.  In Milque, the keystrokes must be Alt'd
   - for instance, Down becomes Alt-Down.


3.2.2.5  Vrsn 0.84 (910828)

3.2.2.5.1   Distributed Screen Layout Peek-A-Boo

   The resource file default layout is such that not all the
   information that can be displayed in a given window is exposed.
   You should try stretching some of the windows to see what's
   there.


3.2.2.5.2   FreeSpace Added to Settings


3.2.2.5.3   Macro Changes To Reduce Redundant Code

3.2.2.5.3.1  General

   Here's what we're doing internally to clean up some of the
   conditional code.  The main changes relate to sb_* flavored
   macros.  MANY of them are simply macro'd to nothingness on the
   Milq side.

   We treat sb_puts(w,s) as a macro on the Milq side, which is
   resolves as follows:

     SendMessage( w, WM_SETTEXT, 0, (long)(char far *)s )

   In other words, on the Milq side, sb_puts is talking to a formal
   Window handle.

   On the Bink side, sb_puts still talks to a Bink window pointer (a
   REGIONP).

   We have far more Windows (essentially, every item displayed on
   the screen has its unique Window.)

   Where old Bink code would look like:

     sb_puts( historywin, str );

   Now it looks like:

     sb_puts( history_hWnd, str );

   With macros on the Bink side resolving it to:

     sb_puts( historywin, str );

   and on the Milq side to:

     SendMessage( historywin->hWnd, WM_SETTEXT, 0, (long)str );

   However, in most cases, the destination of the sb_puts() will NOT
   be a *_hWnd flavored macro.  Each display location has a specific
   window handle on the Milq side:

     sb_puts( history_BBS, str );

   On the Milq side, this will resolve to:

     SendMessage( history_BBS, WM_SETTEXT, 0, (long)str );

   And on the Bink side:

     sb_puts( historywin, str );


3.2.2.5.3.2  Milque Side Detail

3.2.2.5.3.2.1  *_hWnd

3.2.2.5.3.2.1.1  call_hWnd


3.2.2.5.3.2.1.2  file_hWnd


3.2.2.5.3.2.1.3  history_hWnd


3.2.2.5.3.2.1.4  hold_hWnd


3.2.2.5.3.2.1.5  node_hWnd


3.2.2.5.3.2.1.6  settings_hWnd


3.2.2.5.3.2.2  sb_*

3.2.2.5.3.2.2.1  sb_fill*


3.2.2.5.3.2.2.2  sb_move

   sb_move() is history on the Milq side.  It is meaningless.


3.2.2.5.3.2.2.3  sb_puts

   This has been macro'd as follows:

     #define sb_puts(w,s)
              SendMessage(w,WM_SETTEXT,0,(long)(char *)s)

   This requires some macro changes on the Bink side.  Where
   sb_puts() wants to talk to a REGIONP, we now want it to talk to
   an hWnd.  Since we have more hWnds than Bink has REGIONP, this
   seemed the only possible approach.  So we refer to callwin->hWnd
   as call_hWnd, and carry this approach through the five remaining
   windows: File,  History, Hold, Node, and Settings.

   The Bink code is being changed such that sb_moves() talk to
   *_hWnd flavor'd names.


3.2.2.5.3.2.2.4  sb_w*


3.2.2.5.3.3  Bink Side Detail

3.2.2.5.3.3.1  SendMessage

   SendMessage() is reduced to nothing on the Bink side.


3.2.2.5.3.3.2  call_*

3.2.2.5.3.3.2.1  call_hWnd


3.2.2.5.3.3.3  hold_*

3.2.2.5.3.3.3.1  hold_hWnd


3.2.2.5.3.3.4  node_*

3.2.2.5.3.3.4.1  node_hWnd


3.2.2.5.4   Merging to j level source

   We believe we are concurrent with the j level Bink sources.  This
   is roughly equivalent to Bink Beta 2.49-7.


3.2.2.5.5   Node Window Behaviour Changes

   The Node Window behaviour has been refined.  What is displayed
   depends on what window has the focus, and what we are doing.  If
   the Pending window has the focus, the detail information for the
   top line of the window will be displayed.  If you are dialing or
   in a session, the current node information is displayed.
   Otherwise, the last node called info is displayed.

   There are some flaws in the way this works at the current time.


3.2.2.5.6   On Disk Structures Have Changed!

3.2.2.5.6.1  Milque.Scd

   Some elapsed time information, and a more rational way of storing
   last and next address information have resulted in changes to the
   Scd file.  Also, in an earlier release, a change was made to the
   .Scd structure, but the internal version was not incremented.
   This caused problems for some testers.

   Not sure how this will be resolved with Bink.


3.2.2.5.6.2  Milque.Scr

   Changes were made to Milque.Scr to allow storage of more
   information about the state of the screen (although those
   features are not being utilized in this version.)


3.2.2.5.7   Resource File Humour

   The resource file has some elements of humour.  Hope y'all see it
   the same way.


3.2.2.5.8   Spawn Configuration From MEWEL.Ini

   Spawn information is drawn from MEWEL.Ini, which is MEWEL's
   equivalent of Win.Ini.

   To use EMS in swapping, you need to have a mewel.ini containing
   the following:

     [MEWEL.SWAPEXEC]
     UseEMS=1

   The file should be either in the run directory, or in the program
   directory MT lives in.


3.2.2.5.9   UseWinColors added to Milque.Ini

   Added a switch to allow use of the Windows default color scheme.


3.2.2.5.10  Version7 Nodelist Is The Default

   This change was made in 0.83, actually.

   The default nodelist in Milq is V7.  V6 is currently supported,
   but as soon as V7 support is more widely available, Milq will
   support only that format.

   To use V6, you MUST specify the NEWNODELIST verb in Milque.Cfg.


3.2.2.5.11  Windows Menu Item Added


3.2.2.6  Vrsn 0.83

3.2.2.6.1   Call Window Improved

   The call history window has been improved.  It should retain its
   contents and scroll properly now.


3.2.2.6.2   Initial State Info To Milque.Ini

   The current graphics mode is stored in Milque.Ini.  This is a
   Win.Ini flavored file.  A sample is included in the archive.


3.2.2.6.3   Language File Elements Moved To Resource File

   Milque eventually will completely abandandon the language file.
   The Resource File is the "Windowish" way of approaching this.

   At this time, all the data in the language file is contained in
   the resource file as well.  We have drastically cut the product
   code strings contained in the Milque langauge file, as MT is
   using the resource file for this.

   Keyboard translation is currently an amalgam of Accelerators and
   the translation feature added to the language file.  Eventually,
   this will be exclusively a resource file operation.


3.2.2.6.4   Major Window Selection Bug Fixed From Terminal Mode


3.2.2.6.5   Menus Now Accessable Via Keyboard

   We are much closer to Windows-style keyboard handling than in
   earlier versions.  While some work remains, the underlying code
   now reflects the proper path.

   You should be able to access the menus via the keyboard, as well
   as have the alt-key functionality you've gotten used to in Bink.


3.2.2.6.6   Node Detail Information

3.2.2.6.6.1  PWD in Milque.Ini


3.2.2.6.7   Pending Window Operation Vastly Improved

   The Pending Window flashing has been eliminated.

   We've made some changes to the Pending display.  These are
   tentative changes, subject to reversal.  In essence, the address
   field is now right justified, and if you shrink the window
   horizontally, the leading part of the address will be lost rather
   than the information about it.


3.2.2.6.8   Resource File Open Continuously

   The resource file (Milque.Res) is now open all the time.  It can
   be in the directory the main program is located in, or the run
   directory.


3.2.2.6.9   sb_put* Functions Improved


3.2.2.6.10  Screen Size Specific Resource Files

   I don't like this solution, but it works.


3.2.2.6.11  Scrolling Problem in Active Window Fixed


3.2.2.6.12  Shift-Space Access To System Menu


3.2.2.6.13  Tab/Shift-Tab Mailer Mode Window Navigation


3.2.2.6.14  Terminal Mode Colors Somewhat Improved


3.2.2.6.15  VROOMM Buffer Size Reduced


3.2.2.6.16  VROOMM Now Uses EMM/Extended Memory


3.3  Known Limitations/Problems

3.3.1  General (Possibly MEWEL Internal)

3.3.1.1  ComboBoxes Not Coming Down Via Alt-Down


3.3.1.2  Compiled Using BorlandC

   Since it's not overlaid, this is currently not a problem.
   However, once we get back into VROOMM, there could be some
   problems with fileservers.


3.3.1.3  Input Problems

3.3.1.3.1  Desqview "mouse" keyboard not effective


3.3.1.3.2  Hosing of Fabian's Mouse


3.3.1.3.3  Keyboard buffer spooky (Focus Problem)


3.3.1.3.4  Keypad Enter Not Always Effective


3.3.1.3.5  Keypad Enter Not Always Kosher In Size, Move


3.3.1.4  Return From Spawn Hi Res Problems


3.3.1.5  Spawn Configuration From MEWEL.Ini

   Spawn information is drawn from MEWEL.Ini, which is MEWEL's
   equivalent of Win.Ini.

   To use EMS in swapping, you need to have a mewel.ini containing
   the following:

     [MEWEL.SWAPEXEC]
     UseEMS=1

   The file should be either in the run directory, or in the program
   directory MT lives in.


3.3.1.6  SwapDir Config File Verb Not Respected

   The SwapDir config file verb is not respected by Milq.  Instead,
   it uses the TEMP environmental.

   This is an artifact of MEWEL/Windows.  We are not sure how we
   will resolve it, since doing so would involve mucking with MEWEL
   internals.


3.3.2  Mailer Mode

3.3.2.1  Baud Display In Node Detail Not Nearly Right


3.3.2.2  Blank Screen

   Sometimes, upon return from "screenblank", the mailer screen is
   hosed.  The Activity window, and sometimes others are either not
   displayed, or are displayed in a fragmentary manner.  Milque will
   respond to keyboard (and mouse) commands in this state.

   This is a long lived bug.  We continue to improve it, but fail to
   kill it entirely.


3.3.2.3  Node

3.3.2.3.1  Unknown nodes incorrectly identified


3.3.2.4  Path

3.3.2.4.1  Restart Broken?


3.3.2.5  Pending

3.3.2.5.1  Hilight when calling


3.3.2.5.2  Last Line Not Properly Erased


3.3.2.5.3  PageDown/Up Not By Length of Screen, but 4


3.3.2.6  Polling Transition From Nothing In Outbound


3.3.2.7  Transfer Status Problems

3.3.2.7.1  Janus Time/Position Updating

   While dramatically improved, there are still problems with Janus
   transfer updates.

   Further, the adaptations we've had to make to accomodate Janus
   affect the appearance of uni-directional transfer status.


3.3.2.7.2  Terminal Mode


3.3.2.7.3  ZModem Update

   There have been times when updating in ZModem has stopped
   appearing on the screen.  I have yet to identify the conditions
   under which this occurs.  It does NOT interfere with transfers.

   If someone can pin this down, it would be appreciated.


3.3.3  Terminal Mode

3.3.3.1  ANSI Problems


3.3.3.2  Avatar Not Even Implemented


3.3.3.3  External Protocols Not Yet Supported


3.3.3.4  Gateway Mode Nowhere Near Real

   First off, we don't have access to Alt-= under Windows/MEWEL.

   We have yet to make the internal changes to the message
   processors to properly handle it.


3.3.3.5  Keys Randomly Cease Functioning


3.3.3.6  Minimize Should Be Disallowed


3.3.3.7  Redial Nearly Working

   We have totally revamped the redial system.

   Of course, it doesn't work, but you'll get the idea.


3.3.3.8  Transfer Status Problems

3.3.3.8.1  Terminal Mode


3.3.3.8.2  ZModem Update

   There have been times when updating in ZModem has stopped
   appearing on the screen.  I have yet to identify the conditions
   under which this occurs.  It does NOT interfere with transfers.

   If someone can pin this down, it would be appreciated.


4  Testing Desired

4.1  Full Time Node Testing

   Those of you brought in specifically to test Milque are requested
   to run the beast full time on your nodes.

   Beyond that, anyone is welcome to test in whatever capacity they
   wish.


4.2  Response Via BinkBeta